cc: @renatonlima

Olá pessoal,

Fiz um pair programming ontem com o @marcelsavegnago para avançarmos na finalização deste PR.

• O envio / cancelamento / carta de correção estão funcionais.
• A inutilização teve uma regressão no último commit, mas já esta funcionando tb.

Os próximos passos via ser melhorar os últimos detalhes dos eventos e terminar a refatoração do mesmo.

Também quero incluir a opção de salvar ou não os arquivos no disco, que por padrão vai vir ativa.
Isso ajuda até estabilizarmos o projeto, como uma forma redundante de backup dos XML caso a transação não seja commitada.

Depois tem a parte da integração com o l10n_br_account.

@renatonlima fizemos uma redução no código do wizard de inutilização deixando ele mais simples, se puder da uma olhada.

Outra coisa que deu um pouco de trabalho é que não estávamos conseguindo escrever nos campos related da data e número do protocolo, não sei se foi sono, mas achei o comportamento bem estranho. E acabamos então melhorando a questão finalização do evento que serviu da mesma forma.

Os testes ainda não estão passando, mas creio que foi por conta e algumas coisas que foram renomeadas, ainda não focamos nisso.

Vai ser necessário também fazer pelo menos alguns testes funcionais com os módulos do GINFES e ISSNET.

E @renatonlima não sei dizer o que mais você estava planejando no #983, mas se quiser continuar por aqui, fica a vontade para dar push. Só avisa a gnt para não trabalharmos na mesma coisa.

@marcelsavegnago testes verdes =D

Pessoal esse PR esta pronto para revisão, como ficou grande... vamos revisar também.

O script de migração vai ser providenciado nas próximas horas/dias.

Agradeço ao @marcelsavegnago pelo pair programming e tb ao @renatonlima pelo começo do trabalho.

cc: @renatonlima @rvalyi @gabrielcardoso21 @luismalta

Algumas coisas que ainda faltam testar:

• NFS-e Ginfes
• NFS-e ISSNET
• Se haverá incompatibilidade entre esses módulos e o l10n_br_nfe

Ficou um detalhe que ainda não decidimos como proceder:

A invalidação em lote, ou seja vários números ao mesmo tempo, quando só estamos com o fiscal instalado gera um documento fiscal vazio invalidado.

Isso ajuda as pessoas responsáveis pelos documentos fiscais a verificarem a sequência, ou seja se ela olhar na lista dos documentos fiscais vai ver os números invalidados.

Entretanto quando instalamos o account, esses documentos gerados não aparecem na listagem pois não são invoices, batemos um papo rápido sobre isso e decidimos não fazer nenhuma grande mudança e trazer a discussão pra cá. Mas pensamos em algumas possibilidades:

1. Criar uma visão somente leitura dos documentos fiscais, como um relatório, ai não vamos precisar criar uma fatura;
2. Criar mesmo uma fatura, mas onde, em qual diário, ela seria uma fatura cancelada?

[]s

Tudo verde

Rebase feito, aguardando os testes para solicitar o merge!

/ocabot merge major

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 12.0-ocabot-merge-pr-1300-by-rvalyi-bump-major, awaiting test results.

Rebase feito, aguardando os testes para solicitar o merge!

(nem sempre precisar esperar os testes quando a gente tem bastante confiança do que vão continuar passando, pois o proprio merge roda os testes de novo...)

@rvalyi your merge command was aborted due to failed check(s), which you can inspect on this commit of 12.0-ocabot-merge-pr-1300-by-rvalyi-bump-major.

After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red.

/ocabot merge major

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 12.0-ocabot-merge-pr-1300-by-mileo-bump-major, awaiting test results.

Congratulations, your PR was merged at de430a3. Thanks a lot for contributing to OCA. ❤️